About the APIs

vFire has two Application Programming Interfaces (or APIs), which enable you to develop programs to automate many common vFire transactions:

• The Classic API is WCF-based (Windows Communication Foundation).
• The Alemba API is a RESTful API, which is an Application Programming Interface that follows REST (or Representational State Transfer) principles to allow one system to manipulate data in another. It is entity centric – it exposes all the entities within vFire, and the verbs that can be used to manipulate those entities follow the same standard pattern.

The Classic API

The Classic API is the API that has been used throughout vFire until features introduced from 9.7 began using the Alemba API.

The Classic API is procedural – it exposes a defined set of operations (the API Transactions) that manipulate a limited set of entities. You need to know the name of the operation that you want to perform in order to use it.

To find out more, see Classic API.

The Alemba API

The Alemba API was introduced in 9.7 as beta, and GA in 9.9 as a platform for building new interfaces; and to offer a consistent back end for future development.

Its purpose is the same as the Classic API; but the way in which it executes it role, and the scope it offers are vastly different. It offers a much more powerful and intuitive way of working with vFire data.

It is self-documenting, in that you can discover more detail about how to use the API from the API itself. To find out more, see About the Alemba API.

Which API should I use?

Both APIs are shipped as standard from 9.7, and both are running by default.

The Classic API is still in use. However, as time goes on, more and more of the new functionality offered in vFire will rely on the Alemba API. It has supported the vFire apps from 9.7, and the Resource Manager feature introduced in 9.10, and will continue to expand to support more features as releases progress.

The Alemba API is ideally placed to facilitate integrations where someone wants something to happen in vFire as a result of performing an action in another system. A typical example would be logging a request from a company intranet. It is not intended for the exact replication of transactional data, such as calls, from one system to another, as the API applies business logic built in to vFire, such as the setting of reference numbers and timestamps, and the application of workflow rules and agreements.

It should be noted that neither of the APIs expose system configuration settings - and so, are not suitable for data migration/replication used in configuration portability. This is a function in itself. See Configuration Portability for more details.